@matteocoppola following up from my #858 (review) from CIP meeting today (re: does SpendMany "replace" Spend, add to it, modify it, supersede it and/or deprecate it...):

Consensus is that Ledger input (cc @lehins @WhatisRT) is needed to decide how to go ahead with this. Everyone agrees the newly defined purpose is an improvement on the old one, with the old use cases being definable with the new script purpose, but can't be sure if there aren't "edge cases" that would break backwards compatibility: and therefore a requirement for versioning and/or supporting both the old & new script purpose.

Because of this question of scope, as well as feasibility of doing this in the Ledger, we've decided to wait for Ledger's initial feedback with some kind of endorsement before assigning this a candidate CIP number. Once we get to this stage I'll be sure it's on the next CIP meeting agenda.

I'll need to think a bit more about this, but my first thoughts are that this is a great idea. The issue with the redeemer is a bit bigger though, since Ledger also needs to match redeemers to inputs. One idea would be to allow an input to be a list of inputs locked by the same script. Then one can still run the same script with different redeemers while the logic that matches redeemers could be unchanged.

This is definitely a sensible proposal. That being said, we can't do this change for PlutusV1..PlutusV3, since we can't change the context for those versions and addition of a new script purpose is a change to the plutus context. So, we can't "replace Spend", as the title suggests. But, that doesn't mean we can't implement it for PlutusV4. In the matter of fact, I just made a comment on another CIP that we could solve those two proposals with the same solution.

New script purpose could look something like this for plutus:

PV4.SpendingMany [(Integer, TxIn)]

where Integer would refer to the index in the inputs

While for Ledger's redeemer pointer/plutus purpose (i.e. Ledger's script purpose) would look like this:

SpendingMany (Set Word32)

There are a few issues that come with this approach off top my head, neither of which might be an actual problem, but something developers and users need to be aware of. In all of the examples below I assume all inputs are locked by the same script, which would be enforced by ledger:

• Same redeemer is expected for multiple inputs. Naturally, datum supplied and execution units must be the same for an identical execution of a script, so this is something to be expected:

Map.fromList [(SpendingMany [1,2,3], (_ :: Data, ExUnits 123 456))]

• When different behavior is desired it would still be possible to split it up into multiple purposes:

Map.fromList
  [ (SpendingMany [1,2], (a :: Data, ExUnits 123 456)
  , (SpendingMany [3], (b :: Data, ExUnits 1230 4560)
  ]

• Incorrect usage could lead to execution of the same script for the same input multiple times:

Map.fromList
  [ (SpendingMany [1,2], (a :: Data, ExUnits 123 456)
  , (SpendingMany [1,3], (b :: Data, ExUnits 1230 4560)

In this example the script that locks input 1 would be executed twice: once with redeemer (a :: Data, ExUnits 123 456) and the other time with redeemer (b :: Data, ExUnits 1230 4560). That being said, there could be some use cases for this and people actually want this behavior or we could add some ledger rules that prevent duplicate execution. Something that would have to be decided.

• Incorrect usage could lead to execution of the same script for the same input multiple times: ...

... there could be some use cases for this and people actually want this behavior or we could add some ledger rules that prevent duplicate execution. Something that would have to be decided.

@lehins My first thought is I'd be concerned of this increasing the double satisfaction attack surface. From a smart contract's perspective, I don't see how this is different than double spending the input. DApps that don't want this behavior would likely need extra logic to account for the same input being used to satisfy two separate script executions. In other words, these DApps would be burdened by these extra checks just to support the DApps that actually want this behavior. I think this feature will likely be too niche to impose this burden on the remaining DApps.

I would rather the ledger disallow this feature by guaranteeing an input gets exactly one script execution.

@matteocoppola it's noted by @fallen-icarus (#418 (comment)) that this should be considered a solution for candiate CPS-0004. By convention that CIP & CPS would be linked in the header & CIP Rationale so please keep that in mind for future revisions as these documents evolve.